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(57) Abstract: A garbage collector, making use of interior pointers, mainlains a tree stii:;* comprising a plurality of linked nodes 
(40-52), each node being representative of a memory allocation (a...g). For each known in :.sc interior pointer (P) the tree is searched 
to determine the memory allocation (c) to which the pointer points. That memory allc^r./iinn (c) is noted as being unavailable for 
garbage collection release. Once all available in-use pointers have been seaTx:hed for, tho ;"Aem releases those memory allocations 
which have not been noted as unavailable for release. Preferably, the tree is nr. AVL trr:>. \:! he method is applicable to any memory 
allocation scheme, with no constraints on the size of memory allocations nor their pcsitirj:.- ; j memory. The invention further extends 
to a method for garbage coUection and to an operating system including a garbage cclv 
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GARBAGE CQ T.T JTi^TffWJ 

The present invention relates to garbage collection, and particularly although 
not exclusively to garbage collection within an object-oriented environment. 

5 

The e;q)ression "garbage collection" relates to the automatic reclamation of 
computer memory, usually by tiie operating system, when that memory is no 
longer required for the program that is being executed. In some languages such 
ais C or C++, memory allocation freemg must be done e:iq>licitly by the 

10 programmer. In many other languages such as Java (trade mark of Sun 
Microsystems, Inc.) the programmer is freed from the need to worry about the 
releasing of memory allocation by means of a garbage collector which runs in 
the background. Such a garbage collector is part of the Java Virtual Machine 
(JVM). Objects created by the programmer are automatically destroyed by the 

IS garbage collector part of the JVM when no further references to them exist (and 
hence when they cannot again be accessed by the executing program). 

A reference to an object is made when an object Ol contains a pointer or 
handle to another object 02 whereby Ol can access the fields and the call 
20 methods of 02. References to objects can also appear in static (global data) 
and on the processor stack. Conceptually, in Java, these references refer to an 
entire object and to no single part of it. 

When Java code is conq>iled into native code, these references may become 
25 pointers between daita structures (either direct pointers or indirect pointers). 
Typically, these poiiiters refer to the start of (that is^ tiie lowest mqnory 
address of) a data structure repres^odng an object. 
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As an optimisation when generating the native code, it may be useful to create a 
pointer which points to the interior rather than to the start of another data 
structure. If the garbage collector can recognise these interior pointers as 
references , then the native code does not have to save die original pointer to the 
5 start of die data structure; otherwise, the original pointer needs to be saved, 
leading to larger code. 

Mechanisms for efficiently searching for interior pomters do exist, but these 
depend upon forcing a particular memory layout: allocations of similar sizes 

10 are all made fiom the same r^on of memory, starting at a page boundary or a. 
known memory location. Typically, the start memory locations for each of the 
regions are constant, and all are multiples of a factor of 2. With such an 
arrangement, the size of the allocation and its start memory can be determined 
by niasking an interior pointer with the inverse of the fi^ thisgivesthe 

IS pomter to the start of die memory region. 

Such prior art approaches to the garbage collection of mterior pointers are 
wasteful of memory since large blocks of memory need to be allocated, even 
for small objects, to ensure that the memory-blocks are properly aligned (for 
20 example on a page boundary). Inefficient memory allocation of tiiis type can 
be. particularly damaging when programs are to be nm m an embedded 
envkonment, such as a handheld computer or a mobile phone. 

The further difficulty widi conventional garbage collection systems is that ihey 
25 typically dcp&ad upon the details of the particular memory allocation scheme 
that is in use. That may be convenient when the memory allocation is under 
control of die operating system that is carrying out the garbage collection, as it 
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often is, but it is much less convenirat in "hosted" systems in which the 

operating system that includes the garbage collector is ""hosted" on another 

« 

underlying operating system which controls memory allocation. The' fact that 
different underlying operating systems may use different memory allocation 
5 schemes means that different garbage collectors need to be provided in each 
case. This is not only wasteful of programming effort, it is also inconvenient 
smce it makes it virtually impossible to provide a compact and efficient 
operating system, mcluding garbage collection capabilities, which can be hosted 
without amendment on a varied of different underlying operatmg systems. 

10 

It is an object of the present invention at least to alleviate the problems of the 
prior art. 

According to a first aspect of the present invention there is provided a method 
IS of garbage collection mcluding: 

(a) maintaining a tree structure comprising a plurality of linited 
nodes, each node being rq)resentative of a memory allocation; 

(b) for an in-use pointer, searching the tree to determine the memory 
allocation to which the pointer points; and 

20 . (c) noting the said memory allocation as being unavailable for 

garbage collection release. 

The noting of unavailable memory allocations may include marking the 
memory allocation (if it is not already marked) or the corresponding node on 
25 . the tree stracture. The metiiod of the invention may be used in association with 
any convenient mechanism for actually releasing unused memory allocations: 
Preferably, tiiat will hiclude repeating steps (b) and (c) for a plurality of in-use 
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pointers, and releasing those memory allocations which have not been noted as 
unavailable for release. Prefmbly steps (b) and (c) are repeated for all in-use 
pointers, or at least all such pointers which are known to the systmi. 

5 Preferably, the tree is the binary tree, and is searched from tiie top using a 
standard binary traverse. In one particularly convement embodiment, the tree 
is an AVL balanced tree. Standani algorithms may be used to lestnicture 
the tree to maintain its balanced form whenever a new node is added 
corresponding to a new memory allocation, or whenev^ a node is removed 

10 corresponding to a memory allocation beiqg released for re-use. 

The tree need not necessarily be binary, and the invention is applicable to any 
N-way tree, as well as to any N-way balanced tree. 

IS Each memory allocation may represent a contiguous memory block and, in 
object-oriented systems, may represent an individual object. In one form of the 
invention, the objects may be conq)iled forms of Java objects. 

Each node may have, associated with it, information on the block start and the 
20 block end locations; or on one of the said locations and the block length. The 
node may also optionally include other memory allocation-related information, 
for example a block identifier, hi order to define the tree stracture efficientiy, 
each node preferably also includes the addresses of its parent node (if any) and 
its child nodes (if any). 

25 

The tree stroctare may be used to search for ai^ type of pointer, including 
interior pomt^ 
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According to a furttier aspect of the pieseot invention there is provided a 
garbage collector including: 

(a) means for mam tflitiing a tree structure comprising a plurality of 
5 linked nodes, each node being representative of a memory allocation; 

(b) means for searching the tree, for an infuse pointer, to determine 
tbt memory allocations to whidi the pointer points; mi 

(c) means for noting the said memory allocations as being miavailable 
for garbage collection release. 

10 

According to a further aspect of the invention there is provided a metiiod of 
garbage collection including: 

(a) Tnamtaimng a tree structure comprismg a pluraliQr of linked nodes, 
each node being representative of a system memory allocation which 

IS includes one or more garbageHX)llectable memory allocations; 

(b) for an in-use pointCT, searching the tree to determine the garbage- 
collectable memory allocation to which tiie pointer points; and 

(c) noting the said garbage-collectable memory allocation as being 
- unavailable for garbage collection release. 

20 

Acconling to a fiirflier aspect of flie invention there is provided a garbage 
collector including: 

(a) means for maintaining a tree stracture comprising a plurality of 
linked nodes, each node being rq>resentative of a system memory 

25 allocation which includes one or more garbage-collectable memory 

allocations; 

(b) means for searching the tree, for an in-use pointer, to determine the 
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garbageK:ollect£A>le mmcny aUocati and 
(c) means for noting the said garbage-collectable memory allocation as 
beiAg unavailable for garbage collection release. 

S The invention further extends to an operating system and to a JVM (Java 
Virtual lilachine) including a garbage collector as defined. 

In one embodiment, the operating system may include memory allocation 
means so that memory allocation can be controlled as efGcientiy as possible 

10 without any need to introduce artificial constraints on tihe position in memory of 
mCTiory allocations. Alternatively, the operating system may not include any 
memory allocation means, with the garbage collector being arranged to operate 
with memory allocations which have been externally provided. One example of 
this is where the op^atmg system of the present invention is hosted on a 

15 second, underlying operating system; m such a case, the externally-provided 
memory allocations are supplied by the memory allocation means of tiiat 
underlying operating system. Regardless of the memory allocation scheme 
being applied by the underlying operating system, the garbage collector can still 
make use of it. A particular advantage of an operating system having a garbage 

20 collector which can make use of externally-provided memory allocations is that 
such an operating system can be hosted on a variety of different underlying 
systems without any need to worry about the memory allocation scheme used 
by the underlying system. If the underlying system allocation scheme is 
efficient, the operating system will take advantage of that. 

25 

The invention further extends to a conq)uter program for carrying out a method 
as described, to a data carrier carryiog such a conq>uter program, and to a data 
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Stream repres^tative of such computer program. It also extends to a data 
carrier carrying an operating system as described, and to a data stream 
representative of such an operating system. 

S The invention may be carried into practice in a mrmber of ways and one 

specific enibodiment will now be described, by way of example, with reference 
to die accompanying drawings, in which: 

Figure 1 is a schematic representation showing the use of interior 
pointers in optimised native code; 

10 Figure 2 shows allocated memoiy blocks, along with an mterior pointer 

tooneof those blocks; Figure 3 is an AVL tree structure fyr the memory 
allocations of Figure 2, according to the preferred embodiment of the 
invention; 

Figure 4a shows one exemplary memory allocation or ''chunk'' which 
IS forms one of the nodes of die tree; and 

Figure 4b shows an alternative memory allocation, for use when a single 
"chunk** is used for several individual garbage-collectable allocations. 

Figure 1 illustrates schematically details of register and memory usage in a 
20 portion of optimised native code. Data structures 10,12»14 represent individual 
objects, and are held m memory. In addition, machine registers 16 hold 
additional values, typically pointers to the objects held in memory or to 
locations wifliin those objects. As indicated m the figure, register 1 holds a 
pointer 18 (an interior pointer) which points to a particular location wifliin the 
25 object 10. Likewise, the registers 2 and 3 hold mterior pomters 20,22 to 
different locations within the object 14. 
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Pointers may also be held in memoiy as shown by the pomter 24. That is an 
interior pointer within tiie object 10 which points to an. mtemal location within 
the object 12. 

5 Not all of the pointers need necessarily be interior. Pointer 26, for exan^Ie, 
points to the start of the data stroctuie representing the object 12. 

It should be noted that Figure 1 represents optimised native code which need 
not, and typically does not, correspond exactly with the way in which the 

10 individual objects reference one another in the original language such as Java. 
Java itself does not have a concept of interior pointers or even, strictly 
speaking, the concept of pointers at all. Instead, each object can ''reference" 
another object, that reference being to tbe object as a whole and not to any 
individual part of it When the Java code is con:q)iled, those references could 

IS be and sometimes are converted into pointers which point to the start of the daiCa 
structure corresponding to the object in the native code. Native code making 
use only of such pointers would be ineffident, however, and it is accordingly 
preferred in the present invention to create interior pointers as necessary. With 
the interior pointers in place, the original Java pointers which point only to the 

20 start of the object data structures can be dropped. As shown in Figure 1, a 
pointer such as 26 which points to the start of a data structure is retained only if 
tiie code actually needs to reference that address specifically. . 

Figure 2 illustrates the storage of data structures in memory, according to the 
25 preferred ^bodhnent of the invention. Figure 2 shows allocated blocks of 
memory a,b,c..., with memory location address increasing as one moves to the 
right of the figure. Block a starts at memory location A and cods at memory 
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location A'; blodk b starts at mraioiy location B and ends at memory location 
B'; and similarly for the other blocks. The spaces between blocks are shown for 
clarity* and need not necessarily exist. 

S When a new block of monory needs to be allocated, it is allocated in a 
conveni^ memory location, either in an miallocated memory block 30 or, if 
no such block is available, after the last block g. Allocated memory can be of 
any size and may be in any ^position within the addressable memory space. 
There is no constraint, as in the prior, art, of having to allocate memory blocks 

10 of particular sizes or in pardcular predefined locations. 

The role of the garbage collector, when run, is to cbeck each of flie allocated 
mCTiory blocks to see whether it may still be required by the application (or, 
• equivalently , whether there is in existence an inruse interior pointer which 
15 points to that memory block). In order to achieve that end, whenever a new 
block of memory is allocated a referrace to it is added to a bu3ary tree, held m 
memory. 

Figure 4a shows in more detail an individual memory block which corresponds 
20 to a smgle node on die tree. The block or ''chunk" consists of a header 100 
and a data-pordon or ^^payload" 102. The header 100 inchides a section 104 
which defines the node of the tree with which this particular allocation is 
associated, a section 106 which indicates whether die allocation is "large** or 
"small", a section 108 defining the item size, a section 110 which specifies the 
25 start position and a section 1 12 which specifies the end position. In die Figure 
4a example, the section 106 will always be "'large": the ''smaU" option will be 
discussed in more detail below with reference to Figure 4b. The payload 102 
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mchides a header section 114 and a data section 116. 

Figuie 3 shows a typical binary tree representmg the memory allocations shown 
in Figure 2. Each node of fb& tree rq)resents an individoai allocation, and the 
nodes are linked, as described in more detail below, to allow for efficient 
5 searching. The information stored at each node consists of the block identifier 
(d for the node 40), the start address (D) of the block, the end address (D'). 
Alternatively, instead of storing D and D\ one could store either the start of 
the block D or the end of the block D\ along wiOi its length (D* - D). 

10 Each node is also associated with linking information to establish the position of 
the node within the tree. The node. 40, for example, will include. &e 
information that it is linked to two children, namely nodes 42 and -44. Node 44 
includes the information that it has a parent node 40, and two child nodes 
50,52. The node 52 has no child nodes but a smgle parent node 44. The 

15 linking information associated with each node is labelled or ordered such that 
the left hand child node can be distmgiiished from die right hand node. 

An example will now be given of the way in which the tree can be searched to 
identify the memory allocation block to which an unknown interior pointer is 

20 pointing. Jn this example, the unknown pointer will be the pomler P shown in 
Figure 2. Entering at the top of the tree, at flie node 40, a test is first made to 
see whether the value of P is less ttian D. Since P is less than D, we now move 
to the left hand child node 42 which represents the block b. First, we check 
whedier P is less than B. As it is not, we then go on to check whether P is 

25 greater than B'. It is, so we move on to die right hand child block 48. Next, 
we test whether P is less than C, and as it is not we test whether it is greater 
than C\ Since P is neidier less than C nor greater than C\ we conclude that P 
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faHs within tibe block c» and accordingly the search terminates at the node 48. 

Garbage collection is carried out by systematically checking all of the live 
pointers, and nsmg the tree to determine the m^ory blocks within which th^ 
5 £all. No distinction for ibis purpose need be made between interior and other 
pointers: all are simply searched on the tree in the same way. To start, the 
registers are checked for pointers (or the stacks in a stack-based system), and 
the corresponding aUocated memory blocks within which they pomt are 
determined from the tree. Each of diose memory blocks is then checked for 

10 further pointers (using tree-based lookup or any other medianism), and the 
process is repeated. As the process continues, any memory block that is found 
to be in use (i.e. that has a pointer which is directed within it) is marked by 
storing a ''in use** flag against the corresponding node of the tree. Memory 
blocks that are not in use can then be released by die system, and then: 

IS ' corresponding nodes removed from the tree. The tree is dien re-linked into its 
normal binary form. 

It has been assumed, in the discussion above, that a single memory allocation 
corresponds with a suigle node on the tree. In some ckcumstances, however, 

20 it may be more efficient to associate a smgle node on the tree with several small 
garbage-collectable allocations. Such an approach is particularly convenient 
where memory is being allocated from an underlying operating system over 
which the running application has no control. The system memory allocator 
will typically provide system allocations (known as "'chunks"), the timing and 

25 size of which may not be under the control of the applicatiorL 

As shown in Figure 4b, a single system allocation or "chunk" may be used for 
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a number of different garbage-collectable allocations - in this exanq>le indicated 
by the reference numerals 120,122,124. Each of these units includes its own 
header 114 and its own data section 116, within the overall chunk payload 102. 
For ease of con^rehension, the reference numerals used in Figure 4b 
5 correspond with those ahready described above with reference to Figure 4a. 

In the preferred embodiment, the approach of Figure 4b is used if the 
application requires a memory allocation of less than Ik: possible individual 
allocations are, for example, 32, 64, 128, 256, 512 and 1024 bytes. Where 
10 the application reqmres an allocation of greater than Ik, the approadi of Figure 
4a is used. 

In the preferred embodiment, the nodes of the tree represent individual system 
allocations, either as shown in Figure 4a or as shown in Figure 4b, or both. 
15 The header and data sections 114,116 eadi correspond to a single higheMevel 
garbage collectable allocation, for example a Java allocation. 

If the application requires a small allocation (for example less than Ik in the 
preferred embodiment), the whole system block is reserved at the same time 

20 and put onto the tree. The application itself then controls when and under 
what circumstances unused small allocations may be accessed and, if 
appropriate, garbage-collected in their own right without affecting what is on 
the tree. Only when all of the individual allocations associated with all of the 
nodes of the tree are no longer in use is the node and the conesponding system 

25 block itself available for garbage collection. 

It will be understood, of course, tiiat when the approach of Figure 4b is used, a 
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pointer which points to the start of an individual garbage-<:ollectable allocation, 
will, itself, be an ""interior pointer" so far as the entire syst^ block is 
concerned. The method mentioned above of finding the memory allocation to 
which an unknown interior pointer is pointing tiberefore still applies. By 
referencing the item size section 108 of the header, the system is able to 
determine tiiie exact garbage-collectable allocation, within the system allocation, 
to which the interior pointer points . 

It remaios to be determined where in the tree to insert a new node, when a new 
block of memory is allocated, and how ta re-link the tree when one or more 
nodes are ""snipped out" when ^ corresponding blocks are released by the 
garbage collector. There are numerous ways in which this can be done, but 
one particularly convenient approach is to use an AVL load-balancing tree. 
This is a type of bin^ tree which maintains approximate left/right balance by 
the use of appropriate tree-restructuring algorithms both when adding and when 
removing- nodes. Further details are given, for example, hx Donald E. Knuth, 
The Art of Computer Progranimmg, Volume 3. Addison-Wesky, Reading, 
Massachusetts, U.S.A, 1969. Seo dlso Adelson-Velskii, G.M., andE.M. 
Landis. ''An Algorithm for the Organization of Irtfornu^ Soviet Math. 
DocUufy 3, 1962, pp. 1259-1263; and Karlton, P.L., S.H. Fuller, R.E. 
Scroggs, and E.B. Kaehler. "'Performance cf Height-Balanced Trees 
Communications of the ACM 19, 1976, pp.23-28. All of these documents are 
hereby incorporated by reference. ' 

The preferred algorithms, using AVL trees, will now be described in detail. 
First, a little background Balanced binary trees are an efficient general purpose 
data structure. A binary tree is a tree graph each node of which has at most two 
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outgoing edges. Balanced binary trees are structured such that imbalances in size 
between the two subtrees at any node are limited. AVL trees (after Adelsbn- 
Velskii and Landis, who devised the system) are a type of balanced binary tree in 
vMch the two subtrees of any node must always have depths which dif£sr by at 
S most 1 lev6L 

The criterion for balance at a node of an AVL tree is that the difference in the 
height of the two subtrees is never more than one. Height and depth for trees 
are defined as follows: 
10 • Theheightof atreewithnoelemratsisO. 

• The height of a tree with one element is one. The depth of flie root node 
of any tree is 1. 

• The heigiht of a tree with more than one element is the height of the 
tallest subtree phis one. The dq;yth of a node in such a tree is the depth of 

15 its parent, plus 1. 

The 'balanced" property of an AVL tree is mamtained uscrementally in an 
efficient manner (le. taking only time logarithmic m the size of flie tree). 
Whenever a node is inserted or rraioved, one ox more rebalancing 
20 transformations are applied to the tree. 

The three basic operations required are: searching for an element witiiin the 
tree, inserting an element into the tree and removing an element from the tree. 
Note tbBt duplicated values are not pennitted, but that this causes no loss of 
25 generality smce where necessary, an additional fector can be combined with the 
data to be stored to produce a unique key. 
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Terminology and Notation 

The algorithms are described in tenns of 'nodes', 'links' and 'keys'. A node is 
simply a vertex of the tree. Each node has two associated links called the 'left 
S link' and the 'right link', each of which either points to a subtree or takes the 
value NULL (by which we mean that there is no subtree to that side). We use 
'Left(N)' and *Right(N)' to denote the left and right lusks respectively of a node 
N. Every node except the jpot has a unique 'parent' node - which is the node 
one of the links of which points to this node. Each node also has an associated 

10 key. We write Key(N) to denote the key associated with node N. A key is 
sinq>ly the data associated with the node. We assume that there exists a total 
ordering on keys, which we will denote by using the symbol ' < '. For example, 
integer vahies (with the usual meaning of ' < ') would make suitable keys. 
We will also require the notion of a 'direction'. A direction is one of 'left', 

15 'rigjit' or 'balanced' . Every node also has an associated direction, for which 
we write Dir(N) where N is the node in question. We define 'Link(d,N)' as a 
convenient shorthand, where N is a node and d is a direction (not necessarily 
Dir(N)), to refer to a link jQrom a node. Link(d,N) refers to the left link of 
node N if d is 'left' or to the right link of N if d is 'right'. If d is 'balanced' 

20 then the value of Link(d,N) is undefined, but it will never be used in such a 
context. 

If d is a dnection thenby '-d' we mean the opposite direction. E3q)licitiy, if d is 
•left' then -d is 'right' and vice versa. If d is 'balanced' then -d is undefined, 
25 but it wiU never be used m such a context. 
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In our descrq)tioii of the algoritbms, we assume, for clarily, that the root of the 
tree is not NULL - ie. that the tree is not esnpty. Obviously, searching and 
rmoval always fail on an empty tree and insertion results sinq)ly in a tree flie 
root of .which is the inserted element. 

5 

Note that if a link is referred to in a context in whidi we would expect a node, 
it should be taken to refer to the node pointed to by that link. 

The Search Algorithm 
Step 1) Initialise variables 

10 • Define node P to be initially equal to the root node. Node P will be our 

'current point' which will be used to traverse the tree. 

• Define K to be the key we are searching for. 

• We will also use Q to denote a temporary node, which we will define as 
needed. 

15 Step 2) Compare 

• IfK < Key(P)gotostq)3. 

• IfK > Key(P)gotostq>4. 

• UK ^ KBy(^ (bsxwth&yefcmdlSa& el^^ 
C^ofSeaich) 

20 Step 3) Move left 

• Set Q tb Left(P). 

• If Q is not now NULL: set P to Q and return to step 2. 

• Tbe renaming case is if Q is now NULL: this means that the tree did 
not contain an eliement wi& key K, so oar searcb is ended and we return 

25 fiiilure. (End of Seardi) 
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Step 4) Move right 

• Set Q to Right(P). 

• If Q is not now NULL: set P to Q and return to stq) 2. 

• The remaining case is if Q is now NULL: this means that the tree did 
S not contain an element with key K, so our search is ended and we return 

&ilure. (End of Search) 

The Insertion Algorithm 

Step 1) Initialise variables 

• Define 'Head* to be a special node that is not part of die tree but is 
10 considered to be the parent of the root node. Specifically, the right link 

of Head points to the root. This is done so that we need not regard the 
root node as a special case for having no parent 

• Define nodes S and P to be initially equal to the root node. Node P will 
be our 'current point' which will be used to traverse the tree. Node S 

IS will be used to keep track of which subtree should be used as the startuig 

point for rebalancing the tree after insertion. 

• Define node T to be equal to Head. We will always iqwlate T to be the 
parent of S. 

• Defiiiie K to be the tey we are attempting to msert. 

20 •We win also'use Q and R to denote nodes, which we will define as 

needed. 

Step 2) Compare 

• IfK < Key(P)gotostep3. 

• IfK > Key(P)gotostep4. 
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• If K = KeyOP) thra an element of that key already exists within the tree 
and so no insertion is required. (Bndof Lisertkm) 

Step 3) Move left 

• Set Q to Left(P). 

S • If Q is not now NULL: If Dir((^ is not 'balanced' dien set T ID P and S 

to Q. Thai, whatever ttie value of Dir(Q), set P to Q and return to step 
2. 

• The remaining case is if Q is now NULL: we insert our new element 
here. This means that we set Q to be a newly created node (which will 

10 have key K), change Left(P) to point to Q and then go to step 5. 

Step 4) Move right 

• Set Q to Right(P). 

• If Q is<^not now NULL: If Dir(Q) is not 'balanced' th»i set T to P and S 
to Q. Then, whatever tiie value of Dir(Q), set P to Q and return to st^ 

15 2. 

• The remaining case is if Q is now NULL: we insert our new element 
here. This means that we set Q to be a newly created node (which will 
have key K), change Right(P) to point to Q and then go to step 5. 

Step 5) Insert 

20 • Initialise the fields of our new node Q: Set Key(Q) to K, Lefl(Q) and 

Right(Q) to NULL, Dir(Q) to 'balanced'. 

• Proceed to stq> 6. 
Step 6) Adjust balance 

• We need to set the.balance directions on the nodes between S and Q to 
25 reflect the new state of the tree. This is done as follows: 
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• If K < Key(S) then define d as 'left', otherwise, define d as 'right' . 

• Set P to Link(d,S) and define a node R to equal P initially. 

• Repeat the following until P = Q (which may mean 0 times): 

1. If K < Key(P) set Dir(P) to 'left', flien P to Lefl(P). 
5 2. If K > Key(P) set E«r(P) to 'rigjit', then P to Right(P). 

3. (If K = Key(P) then it must be the case that P = Q, so proceed) 

• Proceed to step 7. 

Step 7) Balandng 

• One of three cases applies dq)ending upon the value of Dir(S): 

10 • If IMr(S) = 'balanced' ^n set Dir(S) to d. In this case the insertion is 

now completed. (End of Insertion) 

• If pir(S) is the opposite of d (le. is equal to -d) then set Dir(S) to 
'balanced*. In this case the iosertioii is now conq)leted. (End of 
Insertion) 

15 ,* ^ Dir(S) = d the tree has become unbalanced. We determine how to 
proceed by considermg node R (as defined m st&p 6). If DirOEO is fb& 
opposite of dOe. is equal to -d) then go to step 9.. If pir(R) = dtbengo 
to step 8. Note that it is not possible at this point for eidier to be 
'balanced'. 

20 Step 8) Single rotation 

• We correct an hnbalance in the tree as follows: 

• ■ Set P to R. 

• Set Link(s,S) to Link(-d.R) then Link(-d,R) to S. 

• Set Dir(S) and Dur(R) to 'balanced'. 
25 • GotDStq>10. 
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Step 9) Double rotation 

• .We conect an imbalance to the tree as follows: 

• SetPtoIjnk(<R),fihenLink(<R)toLink(^^^^ 

• Set Liiik(d,S) to Link(-d,P), then Link(-d,P) to S. 

5 • Set Dir(S) and DirOR) depending on the value of Dir(P) as follows: 

1. IfDir(P) = d then set Dir(S) to -d and I>ir(R) to •balanced': 

2. If DirCP) = -d then set Dir(S) to balanced and Dir(R) to 

3. If Dir(P) = 'balanced' then set both Dir(S) and Dir(R) to 
'balanced' as well. . 

10 • Go to step 10. 

Step 10) Correct link. 

• Now we have rebalanced the tree, we must make sure that the parent of 
the rebalanced subtree links to the correct node: 

• If S = Rigbt(I) then set RigM(T) to P, otherwise set I^ft(T) to P. 
15 • Algorittm finished. (End of Insertion) 

The Removal Algorittim 
Step 1) Initialise variables 

• Define 'Head' to be a special node that is not part of the tree but is 
considered to be the parent of the root node. Specifically, the right link 

20 of Head points to the root. This is done so that we need not regard the 

root node as a special case for having no par^. 

• Define PQ to be an array of nodes. So we use P[0], P[l] etc. to denote 
elements wifliin this array. 

• Similarly, define dQ to be an array of directions. 
•25 • SetP[0]to'Head'. 
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• Set d[0] to 'left'. 

• Define node P, set initMy to Rigl]|^[0]) (ie. to tbe root node). 

• Define K to be the key we are attempting to insert. 

• Defineacounter variable c to be an integer, set initially to 1. 

5 • We will also use R and S to denote nodes, whidi we will define as 

needed, and Q to denote a link (not a node) whidi we will also define as 
needed. Note particularly that when we speak of setting Q to some 
(node) value, we mean to point the link Q at that node. 
Step 2) Compare 

10 • IfK < Key(P)gotostq)3. 

• IfK > Key(P)g0tostep4. 

• IfK = Key(P)gotostq>5. 
Step 3) Move left 

• SetP[c] toP. Setd[c]to'left'. 
15 • Add 1 to c. 

• Set P to Left(P). 

• If p is NULL ttien the tree does not contain an element witiik^K so we 
stop here. (End of Removal) 

• Ri^amtost^2. 
20 Step 4) Move right 

• SetP[c]toP.Setd[c] to 'right'. 

• Add 1 toe. 

• SetPtoRigJit(P). 

• If P is NULL then the tree does not contain an element with key K so we 
25 su^here. (End of Removal) 
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• Return to step 2. 

Step 5) Check whether Right link is NULL 

• Define Q to be Ijnk(d[c-l],P[c-l]), ie. the liiik whidi we followed to 
reach P. 

5 • If Rigbt(P) = NULL then proceed to step 6. 

• SetQtoLeft(P). 

If Left(P) is not NULL thenset Dir(Q) to 'balanced' and go to step 10. 
Step 6) Find Successor 

• SetRtoRight(P). 

10 • IfLeftCR)isnotNULL, goiostep?. 

• SetLeft(R)toLefl(P). 

• Set Q to R. 

• SetDir(R)toDir(P). 

• Set d[c] to 'right*, and P[c] to R, then add 1 toe. 
IS • Go to step 10. 

Step 7) Preparation to find NULL Left link 

• Set S to Left(R) and define int^er 1, set initially to c. 

• Add 1 to c. 

• Set d[c] to 'left' and P[c] to R, then add 1 to c again. 
20 • Proceed to step 8. 

Step 8) Find NULL Left link 

• IfLeft(S)isNUIX, proceedtostep9. 

• SetRtoS, flienStoLeft(R). 

• Setd[c] to 'left' andP[c] toR, thenadd 1 toe. 

25 • "Repeat fliis stqp from the beginning (ie. go tq step 8). 



wo 01/73556 



PCT/GBOl/01375 



23 

Step 9) Make adjustments 

• Setd[l]to'right' andPffltoS. 

• Set Left(S) to Leit(P), Left(R) to Left(S) and Right(S) to Rigbt(P). 

• Set Dir(S) to Dir(P). 
S • SetQtoS. 

Step 10) Adjust balance 

• Subtract 1 from c. 

• c is now 0 then stop here. (End of Removal) 

• Set S to P[c], then do one of three diings depending on Dir(S): 

10 •If Dir(S) - 'balanced' , set Dii(S) to -d[c] then stop. (End of Removal) 

• If Dir(S) d[c], set Dir(S) to 'balanced' and repeat diis step from die 
beginning (ie. go to step 11). 

• Otherwise Dir(S) = -d[c], so continue with this step. 

• SetRtoLink(-d[cLS). 

IS • If Dir(R) « 'balanced', go to step 11. 

• If Dir(R) = -d[c], go to stqp 12. 

• We must have Dir(R) = d[c]. Go to step 13. 

Step 11) Sin^e rotation with balanced R 

• Set Link(-d[c],S) to Link(d[c],R), then Link(d[c].R) to S. 
20 • SetDir(R)todic]andIjnk(d[c-l],P[crl])toR. 

• No fiuOier rdialandng is required, so sfoq). (End of Removal) 

Step 12) Single rotation witii unbalanced R 

• Set Link(-d[c],S) to Link(d[c],R), then Link(d[c],R) to S. 

• Set Dii(S) and rHiCR) to 'balanced*. 
25 • SetLink(d[c-l],P[c-l])toR. 
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• Go to step 10. 
Step 13) Double rotation 

• Set P to Lmk(d[c],R), then Liiik(d[c],R) to Liiik(-d[c],P), then Link(- 
d[c].P)toR. 

5 • SetLink(-4[cLS)toIJmk(d[c],P)ta 

• Update balance dkectioDS dq^ending on the valu^ 

• If Dir(P) = -d[c], then set Dn:(S) =^ d[c] and Dir(R) = 'balanced'. 

• If Du:(P) is 'balanced', then set both Dh:(S) and Du:(R) to balanced as 
well. 

10 • OtheiwiseDii<I0 =d[cL sosetDh^ 

• SetDu:(P)tD'bdanced'andLmk(d[c-l],P[c-l])toP, 

• Go to step 10. 

The use of a bmaiy tree for garbage collection allows the invention to be 
15 used on ""hosted" systems, in other words wh^ memory allocation is out of 
the control of the programmer and is determined by an underlying host 
operating system. Since the operation of the invention is essentially 
independent of flie memory allocation scheme being used by the underlying 
operating systraa, the garbage collector of the invention may be used on top of 
20 virtually any underlying operating system that carries out its own memoiy 
allocation. Of course, highly efficient memory allocation will normally be 
achieved only when whichever operating systm is carrymg out the allocation is 
capable of making use of the block size and location flexibility described with 
reference to Figure 2. 

25 



It will be understood that the invaotion is equally applicable to non-binary (N- 
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way) trees, whether balanced or not. It is applicable, for example, to b-trees. 
An A VL tree is merely one preferred mq>lementation of a 2-way balanced tree. 



wo 01/73556 



PCT/GB0iy0137S 



26 

CLABIS 

1 . A mefhod of garbage collection including: 

« 

(a) on the creation of a memoiy allocation, adding a reference to said 
5 allocation to a dynamic tree structare comprising a plurality of linked 

nodes, each node being representative of a respective memory allocation; 

(b) for an in-use pointer, searching the tree to determine the memory 
allocation to which the pointer points; and 

(c) notixig tiie said memory allocation as being unavailable for 
10 garbage collection release. 

2. A method as claimed in claim 1 including repeating steps (b) and (c) for 
a plurality of in-use pointers, and releasing those memory allocations which 
have not been noted as unavailable for release. 

15 

3. A method as claimed in claim 1 or claim 2 in which the tree is a binary 
tree. 

4. A method as clauned in claim 1 or claim 2 in which the tree is an AVL 
20 tree. 

5. ' A method as claimed in any preceding claim in which each memory 
allocation is a memory block. 

25 6. A method as claimed m Claim 5 in which each node has, associated witii 
it, mformation on the block start and the block end locations; or on one of the 
said locations and the block length. 



wo 01/73556 



PCT/GBOl/01375 



27 



7. A method as claimed in any preceding claim in which the in-use pointer 
is an interior pointer. 

5 8. A method as claimed in any one of preceding claims in which the 
memory allocations are not necessarily aligned. 

9. A garbage collector includmg: 

(a) means for creating memory allocations and for adding a reference 
10 to each allocation to a tree structure comprising a plurality of linked 

nodes, each node being representative of a respective mraiory allocation; ^ 

(b) means for searching the tree, for an in-use pointer, to detennina . 
the memory allocations to which tixe pointer points; and 

(c) means for noting the said memory allocations as being unavailable 
IS for garbage collection release. 

10. A garbage collector as claimed in claim 9 including means for searching 
for and noting mejooiory allocations for a plurality of in-use pointers, and for 
releasing these memory allocations which have not been noted as unavailable 

20 for release. 

11. A garbage collector as claimed in claim 9 or claim 10 in whidi the tree 
is a binary tree. 

25 12. A garbage collector as claimed in clann 9 or claim 10 in which the tree 
isanAVLtree. 
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13. A garbage collector as claimed in any one of claims 9 to 12 in which 
each memory allocation is a memory block. 

14. A garbage collector as claimed in claim 13 in which each node has, 
S associated wifli it, infonnation on the block start and the block end locations; or 

on one of the said locations and the block length. 

15. A garbage collector as claimed in any one of claims 9 to 14 in which the 
in-use pointer is an interior pointer. 

10 

16. A garbage collector as claioied in any one of claims 9 to 15 in which the 
memory allocations are not necessarily aligned. 

17. An operating syst^ including a garbage collector as claimed in any one 
15 of claims 9 to 16. 

18. An q>erating system as claimed in claim 17 including memory allocation 
means. 

20 19. An operating system as claimed in claim 17 which does not include 
memory allocation means, the garbage collector being arranged to operate with 
externally-provided memory allocations. 

20. An ojperatmg system as claimed in claim 19 hosted on an underlying 
25 operating system, the externally-provided memory allocations being supplied by 
a memory allocation means of the underlying operating system. 
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21. A computer program adapted to carry out a method as claimed in any 
one of claims 1 to 8. 

22. A data carrier carrying a computer program as claimed in claim 21. 

23. A data stream which is representative of a computer program as claimed 
in claim 21. 

24. A data carrier carrying an cq)erating system as clahned in any one of 
clahns 17 to 20. 

25. A data stream which is representative of an operatmg syst^ as claimed 
in any one of claims 17 to 20. 

26. A method as claimed in claim 1 or a garbage collector as claimed in 
. claim 9 in which the memory allocations are representative of objects within an 

object-oriented system. 

27. A method or a garbage collector as claimed in claim 26 in which the 
objects are the compiled forms of Java objects. 

28. A method of garbage collection including: 

(a) iDaiTitaining a tree structure comprising a plurality of linked nodes, 
each node being representative of a system memory allocation which 
includes one or more garbage-collectable memory allocations; 

(b) for an in-use pointra, searching the tree to determine the garbage- 
collectable memory allocation to which the pointer points; and 
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(c) noting the said garbage*coUectable memory allocation as being 
unavoidable for garbage collection release. 

29. A garbage collector including: 
5 (a) means for maintaining a tree structure conq[>rising a plurality of 

linked nodes, each node being representative of a system memory 
allocation wtdch iacludes one or more garbage-<x)llectable memory 
allocations; 

(b) means for searching the tree, for an in-use poiater, to determine the 
10 garfoageKX>Uec&ible memory aUocation to which the pointer points; and 

(c) means for noting the said garbage-collectable memory allocation as 
being unavoidable for garbage collection release. 



30. A Java virtual machine including a garbage collector as claimed in any 
IS one of Clauns 9 to 16, or as claimed in Claim 29. 
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